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REMARKS 

By this amendment, Claims 1 and 10 are amended and no claims are added or canceled. 
Hence, Claims 1-4, 6, 7, 9-13, 15, 16, 18-20, 39-42, 44, 45, 47-51, 53, 54, and 56-58 are pending 
in the application. 

The amendments to the claims as indicated herein do not add any new matter to this 
application. 

Each issue raised in the Office Action mailed January 7, 2009 is addressed hereinafter. 

I. SUMMARY OF THE REJECTIONS 

Claims 2-4, 6-7, 9, 11-13, 15, 16, 19-20, 40-42, 44, 45, 47, 49-51, 53, 54, 57, and 58 
stand rejected under 35 U.S.C. § 1 12(2) as allegedly being indefinite for recited "A method as 
recited in Claim. ..." It is respectfully noted that one of the acceptable dependent claim wording 
provided in MPEP § 608.01(n)(I)(A) includes "A gadget as in claim 2. ..." Because the MPEP 
allows for this type of wording, reconsideration and withdrawal of the rejection of these claims 
under 35 U.S.C. § 1 12(2) is respectfully requested. 

Claims 1-4, 7-11, 13, 16-20, 39-42, 45, 47-49, 51, 54, and 56-58 stand rejected under 35 
U.S.C. § 103(a) as allegedly being unpatentable over U.S. Patent No. 6,950,822 issued to Idicula 
et al. ("Mcw/a") in view of U.S. Patent No. 5,91 1,143 issued to Deinhart et al. (^Deinhart"), and 
further in view of U.S. Patent No. 6,279,111 issued to Jensenworfh et al. ("Jensenworth"). This 
rejection is respectfully traversed. 

Claims 6, 15, 44, and 53 stand rejected under 35 U.S.C. 103(a) as allegedly being 
unpatentable over Idicula in view of Deinhart and Jensenworth,, and further in view of U.S. 
Patent No. 6,233,576 issued to Lewis ("Levra")- This rejection is respectfully traversed. 
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Claims 12 and 50 stand rejected under 35 U.S.C. 103(a) as allegedly being unpatentable 

over Idicula in view of Deinhart and Jensenworth, and further in view of Official Notice. This 

rejection is respectfully traversed. 



II. ISSUES RELATING TO THE CITED ART 

Claims 1-4, 7-11, 13, 16-20, 39-42, 45, 47-49,51,54, 56-58 stand rejected under 35 
U.S.C. § 103(a) as allegedly being unpatentable over Idicula in view of Deinhart, and further in 
view of Jensenworth. 



A. CLAIM 1 
Claim 1 recites: 

A computer-implemented method for controlling access to a resource of a 

plurality of resources, the method comprising the steps of: 

one or more processors creating and storing in a filesystem of an Operating 

System a plurality of files that each represents a different resource of the 
plurality of resources; 

the one or more processors assigning an access value to a file attribute of a file 
that represents the resource, wherein the file attribute is used by the 
Operating System to manage file access, wherein the access value 
corresponds to a combination of a particular role and the resource; 

the one or more processors receiving user-identifying information from a user 

requesting access to the resource, wherein the user-identifying information 
comprises a role associated with the user, wherein the role is determined 
from a user identifier uniquely associated with the user and from a 
group identifier associated with a group that includes the user; 

the one or more processors receiving a resource identifier associated with the 
resource; 

the one or more processors creating an access identifier based on the user- 
identifying information and the resource identifier, wherein the access 
identifier is formatted as a file attribute that is used by the Operating 
System to manage file access; 

the one or more processors calling the Operating System to perform a file 

operation on the file, wherein calling the Operating System includes 
providing the access identifier to the Operating System; and 

the one or more processors granting the user access to the resource only when 
the Operating System call successfully performs the file operation, 
wherein the Operating System call successfully performs the file 
operation if the access identifier matches the access value; 
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wherein the file operation on the file representing the resource is selected from a 
group consisting of opening the file, closing the file, deleting the file, 
reading from the file, writing to the file, executing the file, appending to 
the file, reading a file attribute, and writing a file attribute, (emphasis 
added) 

1. Discussion of Claim 1 

In an embodiment, resources may be a software application, software application 
message, server, router, switch, file, directory, etc. (Specification, paragraphs 27 and 28). A file 
is created and stored in a filesystem of an Operating System. The file represents a particular 
resource of a plurality of resource. An access value is assigned to a file attribute of that file. The 
file attribute is used by the Operating System to manage file access. The access value 
corresponds to a combination of a particular role and the resource. 

Subsequently, user-identifying information is received from a user who is requesting 
access to that resource. A resource ID associated with the resource is also received, e.g., from 
the user. Subsequently, an access ID is created based on the user-identifying information and the 
resource ID. The access ID is formatted as a file attribute that is used by the Operating System 
to gain access to the file. The Operating System is then called to perform a file operation (e.g., 
open, write, delete) on the file that represents the resource. This is done by providing the access 
ID to the Operating System. The user is granted access to the particular resource when the 
Operating System call successfully performs the file operation. The Operating System call 
successfully performs the file operation if the access identifier matches the access value. 

Because Operating System calls are used to attempt access to a file, a complex security 
mechanism is avoided and application software developers are not required to learn a specific 
API and to write code against it (see specification, paragraph 3). Claim 1 uses the filesystem of 
an Operating System (OS) to manage access to files. The OS filesystem is one of the most well- 
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known and easy to write code systems in a computer system (see specification, paragraphs 4, 7, 

and 8). 

2. Jensenworth fails to teach or suggest that the recited access value 
corresponds to a particular role and a resource 

Claim 1 recites "assigning an access value to a file attribute of a file that represents the 
resource, wherein the file attribute is used by the Operating System to manage file access, 
wherein the access value corresponds to a combination of a particular role and the resource ." 
This access value is later used in conjunction with the recited access identifier that is created 
after a user requests access to a particular resource. The Operating System call successfully 
performs a file operation on the file that represents the particular resource if the access identifier 
matches the access value . 

The Office Action cites col. 5, lines 4-21 of Jensenworth for allegedly disclosing this step 
of Claim 1. This is incorrect. Presumably, the Final Office Action equates the security 
descriptor 76 or access control entries of Jensenworth with the recited access value of Claim 1. 
However, Jensenworth fails to even mention the term "role." Consequently, Jensenworth cannot 
teach or suggest that the security descriptor 76 or an access control entry corresponds to a 
combination of a particular role and a resource , as Claim 1 recites. 

In the "Response to Arguments" section, the Office Action again cites col. 5, lines 4-21 
of Jensenworth and asserts "it would have been obvious to one of ordinary skill in the art that 
said access control list would read upon the limitation of an "access value [which] corresponding 
to a combination of a particular role and the resource." However, this "response" fails to address 
one of Jensenworth^ failings, which is the lack of any reference to " roles ." Thus, Jensenworth 
cannot teach or suggest the recited access value of Claim 1. This failing of Jensenworth is 
related to the failing of Idicula and Deinhart, which is the lack of a role-based access control 
enforced by the filesystem of an OS . 
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3. Deinhart fails to teach or suggest the recited role 

The Office Action cites col. 1, lines 31-36 of Deinhart for allegedly disclosing "wherein 
the role is determined from a user identifier uniquely associated with the user and from a group 
identifier associated with a group that includes the user" as recited in Claim 1. This is incorrect. 
That cited portion of Deinhart merely states that " access rights are granted or revoked explicitly 
for individual users or groups of users on respective data or, more generally, on respective 
objects by a system administrator." This portion of Deinhart is completely unrelated to how a 
role is determined . Specifically, this cited portion of Deinhart fails to teach or suggest that a 
role is determined from two specific identifiers: a user identifier and a group identifier. 

In the "Response to Arguments" section, the Office Action again refers to col. 1, lines 31- 
36 and then asserts that Idicula "discloses an invention wherein user information is used to 
indicate the user' s roles and privileges." Even if this statement were true and Deinhart could be 
combined with Idicula, the combination would still fail to teach or suggest that a role is 
determined from two specific identifiers: a user identifier and a group identifier. 

4. Idicula fails to teach or suggest the recited resource identifier 
Claim 1 further recites: "receiving a resource identifier associated with the resource." 

The Office Action cites col. 7, lines 19-35 of Idicula for allegedly disclosing this step of Claim 1. 

This is incorrect. The applicable part of that cited portion merely states: 

In step 220, a request is received from a client that starts a session. For example, a 
request is received from database client 102a for database services. The database 
server determines whether a session has already been created for this client by 
checking the contents of process state object 130. If a session is already created 
for this client, a session object 122 associated with the client is indicated in the 
process state object 130 . (emphasis added) 

In the "Response to Arguments" section (on page 10), the Office Action equates (1) the session 

object of Idicula with the recited resource identifier of Claim 1 and (2) an "object" of Idicula 
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with the recited resource of Claim 1. The Office Action states, "wherein the object (i.e. the 

resource) being used for the session is identified. That is, wherein a client initiates a session with 

an object, a session object associated with said object is created." It is unclear, however, what 

this "object" of Idicula is to which the Office Action is referring . Perhaps the "object" is the 

database? If another office action is forthcoming, then clarification in this regard is respectfully 

requested . 

Furthermore, as Claim 1 later recites, an access identifier is created based on user- 
identifying information and the resource identifier . Nothing in Idicula that could be equated to 
the access identifier is created based on Idicula's session object (i.e., the alleged resource 
identifier). No other reasonable interpretation of Idicula provides the claimed resource identifier . 

5. Idicula fails to teach or suggest the recited access identifier 

The Office Action cites col. 4, lines 42-56 in Idicula for allegedly disclosing "creating an 

access identifier based on the user-identifying information and the resource identifier, wherein 

the access identifier is formatted as a file attribute that is used by the Operating System to 

manage file access" as recited in Claim 1. This is incorrect. That portion merely states: 

The database server 110 includes memory 120 on the database server host 
computer, which is allocated for use by the database server 1 10. The database 
server 110 maintains several data structures in memory 120. Among the data 
structures maintained in memory 120 are zero or more session objects 122, one or 
more process state objects 130a, 130b, collectively referenced hereinafter as 
process state objects 130, and a session pool object 140. In object-oriented 
technologies, an object is a data structure that stores data that indicates one or 
more attributes or methods or both . An object is one instance of an object type 
that is defined in one or more object type data structures. In other embodiments, 
the data structures that are illustrated as objects in FIG. 1 need not be objects 
according to object-oriented technologies, (emphasis added) 
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This cited portion refers to several data structures that are maintained in memory of a database 

server. In the claims, the recited access identifier is created based on user- identifying 

information and a resource identifier, but the cited portion of Idicula fails to refer to any 

identifiers. Furthermore, this step of Claim 1 recites that the access identifier is formatted as a 

file attribute that is used by an Operating System to manage file access. This cited portion of 

Idicula fails to mention anything remotely related to (a) how an identifier is formatted and (b) an 

Operating System . 

In the "Response to Arguments" section, the Office Action cites col. 7, lines 57-65 of 
Idicula for allegedly disclosing "a method step where the session object is associate[d] with the 
client in the process state object." It is unclear how this responds to Applicants' arguments 
above. 

The Office Action also cites (in the "Response to Arguments" section) col. 5, lines 9-18 
of Idicula for disclosing "Type I" information, which is "user information that indicates a user of 
the associated connection, the user's roles, and the user's privileges." The Office Action then 
asserts that Idicula discloses this step of Claim 1 and specifically refers to type I information as 
disclosing "wherein the access identifier is formatted as a file attribute that is used by the 
Operating System." It appears that the Office Action is equating Idiculd's type I information 
with the recited access identifier. If this were so, then type I information would have to be 
(according to Claim 1) (1) created based on a session object, (2) formatted as a file attribute, and 
(3) used by the OS to manage file access. However, Idicula^ type I information does not satisfy 
any of these criteria. 

6. Idicula fails to teach or suggest calling an Operating System to perform a 
file operation on a file 

The Office Action cites col. 1, lines 52-62 and col. 7, lines 19-30 of Idicula for allegedly 

disclosing "calling the Operating System to perform a file operation on the file, wherein calling 
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the Operating System includes providing the access identifier to the Operating System" as 

recited in Claim 1 . This is incorrect. Nowhere does Idicula teach or suggest that an operating 

system is called in the manner recited. The only portion of Idicula that refers to an operating 

system is the following: 

A session is a related series of one or more requests for services made over a 
communication channel. The channel is typically established by the operating 
system of the host for the database server and that persists for one or more 
communications from the client, depending on the communications protocol used 
by the client, (emphasis added) 

Thus, the only function the operating system of Idicula performs is the establishing of a 

communication channel between a database client and a database server. However, the operating 

system in Idicula is not called to perform a file operation. Therefore, it is not surprising that 

Idicula must fail to teach or suggest that calling an Operating System includes providing an 

access identifier to the Operating System. 

In the "Response to Arguments" section, the Office Action again cites col. 1, lines 52-62 

for disclosing that a "channel is typically established by the operating system." Again, this only 

teaches one function that an operating system performs, and that function is not related to calling 

an OS to perform a file operation on a file, nor does that function involve providing an access 

identifier to the OS . 

In the "Response to Arguments" section, the Office Action also cites col. 4, lines 42-65 
of Jensenworth for disclosing "an invention wherein a Windows NT operating system is used to 
access files, shared memory and physical devices which are represented by objects." However, 
this citation of Jensenworth fails to teach or suggest providing anything similar to the recited 
access identifier to an Operating System, as Claim 1 requires . 
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7. Idicula fails to teach or suggest granting a user access to the resource 
only when the Operating System call successfully performs a file operation 

The Office Action cites col. 7, lines 20-21 of Idicula for allegedly disclosing "granting 
the user access to the resource only when the Operating System call successfully performs the 
file operation" as recited in Claim 1. This is incorrect. As indicated above, the only mention of 
an operating system in Idicula is regarding the establishment of a communication channel 
between a database client and a database server. The single mention of Idicula' s operating 
system is in no way related to the granting of access to a resource . Therefore, Idicula fails to 
teach or suggest this step of Claim 1 . 

In the "Response to Arguments" section, the Office Action disagrees with the above 
arguments without addressing the above arguments. 

8. The Office Action fails to provide a prima facie case of obviousness 

On page 5, the Office Action asserts that it would have been obvious to combine Idicula 
and Deinhart without providing an articulation of a reason for doing so. MPEP § 2143 requires a 
"clear articulation of the reason(s) why the claimed invention would have been obvious." MPEP 
§ 2143 provides some exemplary rationales, but the Office Actions fails to use any of those 
exemplary rationales when combining Idicula and Deinhart. 

Based on the foregoing, the cited art fails to teach or suggest, either individually or in 
combination, all the limitations of Claim 1. Therefore, Claim 1 is patentable over the cited art. 
Reconsideration and withdrawal of the rejection of Claim 1 under 35 U.S.C. § 103(a) is therefore 
respectfully requested. 

B. CLAIMS 10, 18, 39, 48, AND 56 

The Office Action stated the same reasons in rejecting Claims 10 and 18 to those in 
rejecting present Claim 1. Also, Claims 39, 48 and 56 recite features discussed above that make 
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Claim 1 patentable over the cited art. Therefore, for at least the same reasons set forth above by 

in connection with present Claim 1, it is respectfully submitted that each of Claims 10, 18, 39, 48 

and 56 is patentable over the cited art. 

C. DEPENDENT CLAIMS 

The dependent claims not discussed thus far are dependent claims, each of which depends 
(directly or indirectly) on one of the independent claims discussed above. Each of the dependent 
claims is therefore allowable for the reasons given above for the claim on which it depends. In 
addition, each of the dependent claims introduces one or more additional limitations that may 
independently render it patentable. 

1. Claims 7, 16, 45, and 54 

It is respectfully noted that the Office Action fails to address any of the arguments, in the 
last response, regarding Claims 7, 16, 45, and 54 . For convenience, those arguments are 
repeated as follows. 

The Office Action asserts that Claims 7, 16, 45, and 54 do not: 

carry patentable weight since the claim recites the file operation of 'opening the 
file representing the resource,' which was optionally recited in Claims 1, 10, 18, 
22, 31, 39, 48, and 56..., upon which the said respective claims depend. 
Therefore, since the opening of the file is optional and not necessary to the 
claimed invention, the claim is rejected, (pages 5-6) 

This rationale is inconsistent with well established patent practice principles. To review, Claim 1 

recites that the file operation could be any of the recited operations. Thus, if there is prior art 

that anticipates or renders unpatentable all the other features of Claim 1, the prior art would only 

have to additionally teach or suggest that the recited file operation is one of the recited 

operations. Claim 7 depends on Claim 1 and further limits Claim 1 by reciting, among other 

things, the step of opening the recited file. Therefore, the opening of the file is no longer 
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optional in Claim 7. Therefore, the Office Action's premise that the opening of the file is 

optional is incorrect. Furthermore, the Office Action has failed to cite any references for 

teaching or suggesting the steps of Claim 7 that are not found in Claim 1. 

Due to the fundamental differences already identified and to expedite the positive 

resolution of this case, a separate discussion of those limitations is not included at this time. The 

Applicants reserve the right to further point out the differences between the cited art and the 

novel features recited in the dependent claims. 

III. CONCLUSIONS & MISCELLANEOUS 

For the reasons set forth above, all of the pending claims are now in condition for 
allowance. The Examiner is respectfully requested to contact the undersigned by telephone 
relating to any issue that would advance examination of the present application. 

If any applicable fee is missing or insufficient, throughout the pendency of this 
application, the Commissioner is hereby authorized to charge any applicable fees and to credit 
any overpayments to our Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Dated: April 6, 2009 /DanielDLedesma#57 181/ 

Daniel D. Ledesma 
Reg. No. 57,181 

2055 Gateway Place Suite 550 
San Jose, California 95110-1083 
Telephone No.: (408) 414-1080 ext. 229 
Facsimile No.: (408) 414-1076 
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